home *** CD-ROM | disk | FTP | other *** search
/ AmigActive 10 / AACD 10.iso / AACD / Resources / Online / Term / Extras / HydraCom / amiga.notes next >
Text File  |  1996-09-05  |  7KB  |  140 lines
  1. HYDRA protocol sample implementation, Amiga port rev.8 by
  2.  
  3.     Olaf Barthel
  4.     Brabeckstrasse 35
  5.     D-30559 Hannover
  6.  
  7.     eMail: olsen@sourcery.han.de
  8.  
  9. The Amiga support modules are freely distributable. For further information
  10. on   the   remaining  distribution  refer  to  the  files  `hydra.asc'  and
  11. `hydra.doc'.
  12.  
  13. Many  thanks  to  James  McOrmond  who supplied the HYDRA source code. This
  14. program  was  compiled using the SAS/C compiler, it requires Kickstart 2.04
  15. or higher to run.
  16.  
  17.                                 *
  18.  
  19. What is HYDRA?
  20. ==============
  21. HYDRA  is  a  bidirectional  file  transfer protocol designed by Joaquim H.
  22. Homrighausen  and  Arjen  G.  Lentz  similar to Bimodem, a proprietary file
  23. transfer protocol. It originated in the PC world and, as far as I know, has
  24. been ported only to the Atari ST yet. This distribution adds an Amiga port.
  25. The HYDRA protocol can send and receive data at the same time and also adds
  26. a chat option.
  27.  
  28.  
  29. What about the source code?
  30. ===========================
  31. The  source code included in this distribution was edited slightly to allow
  32. the   Amiga   implementation  to  work  properly.  The  original  code  was
  33. busy-polling  keyboard  and  serial  line,  a  feature  which  needed to be
  34. replaced  by  multitasking  friendly code on the Amiga side. The Amiga port
  35. tries  to  emulate the asynchronous serial I/O code the original PC version
  36. of the HYDRA protocol sample implementation would use.
  37.  
  38.  
  39. What about the documentation?
  40. =============================
  41. The  file  called  `hydra.doc',  to  be  found  in  the  `source' directory
  42. describes the HYDRA sample protocol implementation in detail. Refer to this
  43. file for more information on the program.
  44.  
  45.  
  46. Differences between the Amiga port and the original program
  47. ===========================================================
  48. The  original implementation did not support the "DEVICE" keyword which was
  49. added to the Amiga port in order to allow third party serial device drivers
  50. to  be used. The split-screen technique used by the original implementation
  51. was  replaced  by  multiple console windows. Pull-down menus partly replace
  52. the  odd  keyboard  commands supported by the original implementation, i.e.
  53. some keyboard commands work, some don't. There is no Fossil support in this
  54. implementation  ;-)  All the features of the original implementation should
  55. work,  although  some  may  not  make  much sense on the Amiga. There is no
  56. separate HydraCfg program.
  57.    Where  I  needed to make changes to the source code my tag "/* OLSEN */"
  58. indicates where to look for changes.
  59.  
  60. What's different in revision 2 of this port?
  61. ============================================
  62. I  had  overlooked some MS-DOS dependancies in the source code, namely path
  63. and  file  name  lengths  which used to be limited to 13 and 90 characters,
  64. respectively. Where such restrictions were obvious they were removed.
  65.    HydraCom  now  offers an interface to the forthcoming new `term' release
  66. and  in  fact  any  other  terminal program that provides the same hooks as
  67. `term'.  If  you  give  the  name  of the ARexx port `term' has open as the
  68. device  name (i.e. "device TERM") HydraCom will try to interface to `term'.
  69. If  successful,  HydraCom will take over serial device processing, blocking
  70. `term'  access  to the serial driver. When HydraCom is  in posession of the
  71. serial  driver  you  may  transfer files as usual, but remember that `term'
  72. itself  will  be  disabled  while  HydraCom is running. When finished, quit
  73. HydraCom, this will return control back to `term'.
  74.  
  75. What's different in revision 3 of this port?
  76. ============================================
  77. The  device  was  not  opened  in  shared  mode,  a feature many users have
  78. requested.  The  window  setup  no  longer  requires 25 lines to fit on the
  79. screen, now 20 will do.
  80.  
  81. What's different in revision 4 of this port?
  82. ============================================
  83. Hydracom now looks for the Hydracom.cfg file in the same drawer the program
  84. itself is found in first (for example, if you would have Hydracom stored in
  85. the    "Work:term"    drawer,    it    would   try   to   open   the   file
  86. "Work:term/Hydracom.cfg"  upon  startup). When preparing a list of files to
  87. upload,  you  can now use a standard file requester to pick the files from.
  88. Note  that  a file transfer currently in progress will *continue* while you
  89. pick  the  files  to  send.  When  initializing itself, the program will no
  90. longer  complain  if less than 20 lines are available for the input window;
  91. the  new  minimum  value are three lines. The receive and send drawer names
  92. did not get proper path separator characters appended; this caused files to
  93. appear  in the wrong drawers. File names are no longer converted into lower
  94. case  characters  only.  A  very crude CPS calculation routine now supplies
  95. data for the transfer progress display. The "Sending" and  "Receiving" text
  96. was off by one line. This has been fixed.
  97.  
  98. What's different in revision 5 of this port?
  99. ============================================
  100. Previous  Hydracom  releases  would  set  invalid  file creation dates. The
  101. frequent  calls  to  time()  would also be very costly in terms of speed. I
  102. wrote  replacements  for  all  routines  involved  in  setting, getting and
  103. converting  times and dates. They should be both faster and shorter now. In
  104. addition  to this the new routines pay attention to the current locale time
  105. zone  settings,  always ignoring the global TZ variable. Please note that I
  106. expect  that  the Atari ST and IBM-PC implementations of the Hydra protocol
  107. will  transmit  time  and  date  values  with less precision than the Amiga
  108. version does.
  109.  
  110. What's different in revision 6 of this port?
  111. ============================================
  112. The cps display (which, by the way, is not very accurate) no longer causes
  113. the window contents to scroll away on narrow screens. I walked through the
  114. code and  tried to find  the Bermuda  triangle where all the file names to
  115. include blank spaces  would vanish. I  knocked over a  bunch of tokenizing
  116. routines, that should do it. On error  or abort,  hydracom will  no longer
  117. return result codes  to the shell  that invoked  it that are difficult  to
  118. react upon. If something went wrong, 5 will be returned, otherwise it will
  119. be 0. This  makes it  possible  to check for  "WARN" conditions in  script
  120. files and such. Hardware handshaking never got activated, the code did not
  121. get called, now it does. All console windows  now sport the main pull-down
  122. menu, not just the bottommost one. The  maximum  block  size is no  longer
  123. limited to 256 bytes, some code got lost.
  124.  
  125. What's different in revision 7 of this port?
  126. ============================================
  127. Temporary file creation should work reliably now, permitting to run
  128. multiple copies of the program from the same drawer. When going through
  129. the `term'<->Hydracom rendezvous interface, Hydracom now uses the baud
  130. rate and serial parameters passed with the rendezvous data. In this case
  131. Hydracom will ignore the command line options for speed and parity. I also
  132. went through the code and made sure that when receiving files, existing
  133. files will get skipped.
  134.  
  135. What's different in revision 8 of this port?
  136. ============================================
  137. The number of error retries is now configurable. I rewrote the code that
  138. puts up the file requester when collecting file names. This made the
  139. program pure, it can be made resident now.
  140.